Windows Server 2003 : Using IAS to Protect the Network from Bad Computers

Host-hardening techniques for LAN computers can prevent (or at least mitigate the results of) a malicious attack that evades or compromises perimeter protections. IAS server does offer unique functions that can assist you in the new security techniques of client network access policy compliance evaluation.

Two techniques are recommended: network access quarantine control and network access protection (NAP). Network access quarantine control is the process of isolating untrusted computers that request remote access until they can prove that they meet a defined network access policy. NAP is the process of providing a similar security review for clients connecting to the LAN. To use either requires extensive research, scripting, and network provisioning to meet the needs of the organization's security policy. In addition, it should be realized that neither are defenses that can protect the network from a determined attacker. Instead, they are defenses that protect the network from bad computers. Bad computers are those that do not use any hardening techniques (such as a personal firewall, antivirus products, and keeping patching up to date). These computers are more likely to be infected or compromised and, thus, more likely to spread infection or serve as a platform for an attack if connected to the LAN.

1. Network Access Quarantine Control

The normal remote access process validates the credentials of the requesting user. Requiring computer authentication can ensure that only authorized computers (as well as authorized users) obtain remote network access. However, nothing about the process or the connection can prevent an authorized connection from providing a path for attacks, whether malicious or unintentional (as in the spread of malware such as viruses and worms). If the remote client is compromised, remote access does nothing to prevent the client computer from being used to compromise the LAN.

Network Access Quarantine Control can prevent (or mitigate the impact of) compromised or infected computers that are used for remote access by users with valid credentials. It does this by requiring that the remote computer be inspected for adherence to a network access policy. The policy is designed by the organization and implemented in the form of a script that runs on the remote client. The script attempts to determine if the computer meets the security policy requirements. The script might be designed, therefore, to answer the following questions:

• Does the client have a personal firewall enabled?

• Does the client have antivirus protection enabled using a specific (or perhaps one of many acceptable) antivirus product?

• Is the antivirus product engine up to date?

• Are the antivirus product signatures up to date?

• Does the client have the most recent service pack installed?

• Is routing disabled?

• Is a password-protected screensaver with an adequate wait-time active?

• Is the client up to date with patches?

1.1. Understanding network access quarantine control

Network access quarantine control works by providing a quarantine network for untested clients and those not in compliance with the network access policy; the client cannot access any other portion of the LAN until the security policy is met. The quarantine can be a network subnet that provides resources the client can use to update security products and find information on required policy restrictions, or it may merely provide information on how clients can meet conditions and prevent clients from connecting until they do.

Two types of restrictions, quarantine restrictions and time restrictions, are generally used, though there is no requirement to use either. Quarantine restrictions are a minimum of a set of packet filters that restrict traffic that can be sent to and from a quarantined remote access client. Time restrictions add a quarantine session timer that restricts the amount of time the client can be connected. Providing time restrictions can cause problems for legitimate clients attempting to update their systems using the quarantine network resources, but also limits the amount of time attackers might use to attempt to find ways around the quarantine.

The following components are used to implement network access quarantine control:

Quarantine compatible remote access clients

These are computers that support Connection Manager (CM) profiles created by the Windows Server 2003 Connection Manager Administration Kit (CMAK). This includes Windows Server 2003, Windows XP Professional and Home Edition, Windows 2000, Windows Millennium Edition, and Windows 98 Second Edition.

CM profiles

These include a post-connect action that runs the network access policy script, a copy of the network access policy requirements script, and a notifier component to inform the remote access server that a script was run successfully. The Windows Server 2003 Resource Kit provides the rqc.exe notifier. (Third-party dialer programs may be used if they can be configured to run a post-connection action to install the script, run it, and notify the remote access server.)

Quarantine compatible remote access server

This is a Windows Server 2003 RRAS server configured to support the listener components such as the Resource Kit rqs.exe software and the MS-Quarantine-IPFilter and MS-Quarantine-Session_Timeout RADIUS vendor-specific attributes. These are used to enforce quarantine settings. The listener component listens for notification from the notifier component in the CM profile that announces the remote client meets the security policy.

Quarantaine compatible RADIUS server (optional)

The RRAS server can be configured to use Windows authentication and, therefore, a RADIUS server is optional. If an RRAS server is used, Windows authentication is selected and the vendor-specific attributes must be configured in the RRAS Remote Access policy. When RADIUS is used, the vendor-specific attributes must be configured in an IAS server Remote Access policy.

Quarantine resources

Connecting remote clients must have access to appropriate resources before they are approved for network access. These resources should reside on the quarantine network and are name resolution servers such as DNS, access to the latest CM profile (remote, anonymous access), or access instructions and components required to make the client meet the network policy (such as web servers with anonymous access allowed). Anonymous access is required even though the client uses authorized credentials to access the remote access server, since the client might not be using the domain credentials required for domain member web resources. The location of these resources can be on a special quarantine network, or on the intranet. If resources are on the intranet, special packet filters must be configured to allow access to them, though this access may pose a security concern because it allows access to the LAN.

Accounts database

This is either AD or Windows NT 4.0 domain user database.

Notifier component

This consists of a notifier (rqc.exe) and a listener (rqs.exe), which are two programs available from Microsoft.

Quarantine remote access policy

The remote access policy includes the MS-Quarantine-IPFilter and MS-Quarantine-Session_Timeout RADIUS vendor-specific attributes. The MS-Quarantine-IPFilter attribute contains the input and output packet filters that allow traffic generated by the notifier component. This traffic includes specific notifier messages on port 7250, DHCP messages, and any traffic to access quarantine resources.

Figure 1 shows these components and provides a numbered flowchart for the process. In this scenario, a RADIUS server is used.

Figure 1. Client access to the intranet is limited to the quarantine network until it is evaluated against a network access policy

Following are the steps shown in Figure 10-33:

1.2. Implementing network access quarantine control

Instructions on implementing network access quarantine are beyond the scope of this article because:

• Many third-party applications may be part of an organization's remote client setup.

• A custom notifier, listener or other scripts may be used.

• The security policy for network access will vary.

However, the following are generic instructions. First, create quarantine resources. Create a script or program that validates client configuration. Install rqs.exe or another listener component on the RRAS servers. Create a quarantine CM profile with the Windows Server 2003 CMAK. The profile must include the rqc.exe or other notifier and the script. Distribute the CM profile for installation on remote access client computers. Configure a quarantine Remote Access policy.

To create the Remote Access policy, create a Remote Access policy whose conditions either affect all remote access connection attempts, or create a mixture of Remote Access policies with at least one that includes the remote access attributes IPFilter and Timeout. Although it may seem silly to allow remote access connections where the security policy is not evaluated on the remote access client, it is difficult to establish a script that will provide perfect results on all clients, especially when first implementing the new remote access policy. If at least one Remote Access policy does not require quarantine controls, it will be possible to provide access to clients that fail the script, at least until it can be determined why they failed (even though every attempt was made to make them compliant), and the script adjusted.

While evaluating every client and denying those that don't meet the specs will reduce the chance of infection via a compromised remote client, allowing critical access to network resources may be judged of higher importance Some manual method should be used to qualify remote access clients before they are added to the quarantine-free remote access policy. Access can be granted by adding them to a Windows groups identified by the policy as a condition of policy use.

Creating a remote access policy for quarantine is not difficult because it consists of creating a policy via the normal method. Follow the instructions provided earlier in this article, but instead of adding attributes specific to those implementations, add the quarantine attributes listed here. Specifics of the policy should include

• Conditions such as membership in a Windows group (time-of-day and such)

• Access method of VPN

• Addition of any normal constraints

• Addition and configuration of the MS-Quarantine-Session-Timeout attribute and the MS-Quarantine-IPFilter and Timeout attributes.

To configure the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout attributes, begin by opening the Remote Access policy. Click the Edit Profile button. On the Advanced Profile page, click the Add button. Select the MS-Quarantine-IPFilter attribute and click Add. In the IP Filter Attribute Information box, click Input Filters. In the Inbound Filters dialog box, click New to add a filter. Select TCP or UDP in the protocol drop-down list. Enter the source or destination port as defined in Table 1. Click OK. Repeat for each required port. Click "Permit only the packets listed below as shown." Click OK to save the filter list. On the Advanced Profile page, click the Add button. Select the MS-Quarantine-Session-Timeout attribute and click Add. In the Attribute Information box, enter the quarantine session time in the Attribute value box in seconds. Then click OK. Click OK to save the profile settings. Click OK to save the changes to the Remote Access policy.

To configure the packet filters for the IPFilter attribute, use the standard ports as defined in Table 10-10, or create services running on alternative ports and configure packet filters that allow those ports.

For more information on implementing network access quarantine control including a sample script, obtain the KB document Microsoft Windows Server 2003 Network Access Quarantine Control, at http://www.microsoft.com/windowsserver2003/techinfo/overview/quarantine.mspx.

2. Network Access Protection

When network access quarantine control was first announced, many people asked if it could be used for restricting access to the LAN by inspecting each new connection attempt. They reasoned that laptops returning to the local LAN from use on other untrusted networks are just as likely to spread infection as untested remote access clients. Sadly, this is not now possible. Network access quarantine control is implemented using RRAS and RADIUS, and the IAS server can be used to manage access via wireless networks and authenticating switches. However, network access quarantine control cannot be used for wireless networks or with authenticating switches because it requires the use of a RRAS service and the ability to run a post-connect script on the wireless client or switch client. However, alternative methods for doing security compliance testing are possible. Two methods are:

• Providing a network policy compliance script that is run as part of the computer's startup and domain logon sequence (wireless clients and switch clients do require a domain account)

• Using Network Access Protection (NAP )

NAP is currently scheduled to be released with the next release of Windows (code-named Longhorn).